Method and system for modifying properties of graphical user interface components

ABSTRACT

A method, computer program product, and data processing system for modifying attributes of GUI components without invasive code modification are disclosed. In a preferred embodiment, a set of attributes for GUI components is loaded into memory from persistent storage, such as a file. A root container component forming the root of a hierarchy of components defined by a containment relation is identified and passed as a parameter to a routine that traverses the hierarchy so as to visit each GUI component. As each GUI component is visited, if one or more attributes from the aforementioned set of attributes are found to be applicable to the visited GUI component, the GUI component&#39;s attributes are modified to comport with the set of attributes.

BACKGROUND OF THE INVENTION

1. Technical Field

The present invention is related generally to software that provides agraphical user interface. Specifically, the present invention isdirected toward providing a means of modifying the properties ofgraphical user interface components without resorting to extensivechanges in source code.

2. Description of Related Art

Many computer software products today utilize a graphical user interfaceor GUI (typically pronounced like “gooey”). A GUI is simply a visualmeans of human-computer interaction that utilizes pictures or othervisual representations besides text or characters.

Most GUIs make use of visual controls that are displayed on the user'sdisplay and actuated by user input in order to provide input to thesoftware associated with the GUI. In a typical GUI, a pointing device,such as a mouse, is used to move a cursor around a display and actuatevisual controls. A GUI will typically also make use static displaycomponents, such as icons or text, for the display of information.

Many GUIs are what is known as a “windowing” interface, because theyarrange information visually on a display in the form of panels or“windows” superimposed on a background called a “desktop.” Typically, awindow will contain a number of visual controls and static displaycomponent to facilitate user interaction.

Windows, visual controls, and static display components are what areknown as GUI components, because they are the building blocks that makeup the GUI. Some GUI components, such as windows, are known as“container components” (or simply “containers”), because they maycontain other components. Because a container component is itself acomponent, a container may also contain another container.

Container components include windows, but may also include othercomponents, which may be visible or invisible. Some GUIs make use ofinvisible container components to group other components together insome visual arrangement or non-visual relationship (e.g., mutuallyexclusive checkboxes).

Many modern programming language implementations have built-in featuresfor producing GUIs, usually either by providing an interface to servicesprovided by system-level software or by including standard libraries ofGUI code. The JAVA™ programming language, for example, is anobject-oriented programming language that includes standard applicationprogramming interfaces (APIs) for defining GUIs. Two APIs that arecurrently part of the JAVA™ programming language standard are theAbstract Windowing Toolkit (AWT) API and the Swing API. In the JAVA™programming language, as is typical of object-oriented GUI APIs, eachtype of GUI component is defined as a class. In an object-orientedprogramming language, a class is a definition of a data type thatincludes a collection of data, called member variables, and a set ofoperations that may be performed on the data, called methods (oralternatively, member functions). An actual collection of data in thedata type defined by a class is called an object. In object-orientedprogramming (OOP) parlance, an object is said to be an “instance” of itsclass, because it is an actual item of data that is defined inaccordance with the class. The run-time process of generating an objectin an object-oriented programming language is called “instantiation,”and an object that exists at run-time is said to be “instantiated.”

Object-oriented programming languages also typically provide for what isknown as “inheritance.” Using inheritance, a new class (called a“descendant” class) can be defined in terms of one or more existingclasses (called “base” classes) so that the descendant class inheritsone or more of the member variables or methods of the base class. As ageneral rule in object-oriented languages, an object of a descendantclass can be treated as being an instance of the base class. Thisability to treat objects from descendant classes as if they wereinstances of base classes is called “polymorphism.”

In an object-oriented GUI API, such as those provided by the JAVA™programming language, GUI components are instantiated as objects, andrelationships are established between the instantiated objects in orderto define the placement and behavior of GUI components with respect toeach other. For example, a “containment relation” is a relationshipbetween GUI components that relates a container component to thecomponents contained by that container component. In an object-orientedGUI API, for example, container classes may define methods thatestablish a containment relation by making the container contain someother component.

A typical GUI component has one or more attributes that defineparticular properties of the component. For example, a “button”component in a typical GUI will have attributes that define the size ofthe button on the display, the text or graphics displayed on the face ofthe button, the background color of the button, a keyboard shortcutassociated with the button, and the like. In general, the portion ofprogram code (e.g., function, method, subroutine, procedure, etc.) thatinstantiates a GUI component will also contain a number of lines of codethat set the attributes for that component to desired values.

Sometimes, the general look or GUI content of an entire computer programneeds to be modified. In cases such as these, different attributes forthe GUI components will need to be set. For example, it may be necessaryto enlarge all of the GUI components and their text if a program isbeing adapted to be used by users with poor eyesight. As anotherexample, if a program is being adapted for users speaking differentlanguages, the text, character set, and component sizes may need to bemodified. If the code that sets attributes for each component is buriedwithin the source code for the program along with the code forinstantiating the components, this means that an exhaustive search andcareful modification of the of the source code is necessary in order toeffect this sort of large-scale or global change in GUI display orbehavior.

As another example, it is sometimes necessary to adapt a program toexecute in multiple display modes. For example, it may be necessary touse different colors at different times of the day. In such cases,global changes to an existing GUI display at run-time will be necessary.

GUI component attributes for a single component are difficult to modify,as well, because the code for setting attributes for that component maybe buried within many lines of code or even spread out across a largeprogram.

Thus, a need exists for a means to effect large-scale or global changesto attributes of GUI components without invasive program codemodification.

SUMMARY OF THE INVENTION

The present invention provides a method, computer program product, anddata processing system for modifying attributes of GUI componentswithout invasive code modification. In a preferred embodiment, a set ofattributes for GUI components is loaded into memory from persistentstorage, such as a file. A root container component forming the root ofa hierarchy of components defined by a containment relation isidentified and passed as a parameter to a routine that traverses thehierarchy so as to visit each GUI component. As each GUI component isvisited, if one or more attributes from the aforementioned set ofattributes are found to be applicable to the visited GUI component, theGUI component's attributes are modified to comport with the set ofattributes.

BRIEF DESCRIPTION OF THE DRAWINGS

The novel features believed characteristic of the invention are setforth in the appended claims. The invention itself, however, as well asa preferred mode of use, further objectives and advantages thereof, willbest be understood by reference to the following detailed description ofan illustrative embodiment when read in conjunction with theaccompanying drawings, wherein:

FIG. 1 is an external diagram of an example of a data processing systemin which the present invention may be implemented;

FIG. 2 is a block diagram of an example of a data processing system inwhich the present invention may be implemented;

FIG. 3 is a diagram of a file containing a set of attributes to beapplied to instantiated GUI components in a preferred embodiment of thepresent invention;

FIG. 4 is a class diagram of component and container classes in theobject model of a GUI that may be used in conjunction with a preferredembodiment of the present invention;

FIG. 5 is a diagram of a hierarchical set of GUI components defined by acontainment relation;

FIGS. 6A-6B are together a diagram of an attribute application routineexpressed in a JAVA™-like pseudo code in accordance with a preferredembodiment of the present invention;

FIG. 7 is a flowchart representation of a process followed by run-timeenvironment to apply attributes to instantiated GUI components in apreferred embodiment of the present invention; and

FIG. 8 is a flowchart representation of a process followed by anattribute application routine to apply attributes to GUI components in ahierarchical set of GUI components in accordance with the preferredembodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

With reference now to the figures and in particular with reference toFIG. 1, a pictorial representation of a data processing system in whichthe present invention may be implemented is depicted in accordance witha preferred embodiment of the present invention. A computer 100 isdepicted which includes system unit 102, video display terminal 104,keyboard 106, storage devices 108, which may include floppy drives andother types of permanent and removable storage media, and mouse 110.Additional input devices may be included with personal computer 100,such as, for example, a joystick, touchpad, touch screen, trackball,microphone, and the like. Computer 100 can be implemented using anysuitable computer, such as an IBM eServer computer or IntelliStationcomputer, which are products of International Business MachinesCorporation, located in Armonk, N.Y. Although the depictedrepresentation shows a computer, other embodiments of the presentinvention may be implemented in other types of data processing systems,such as a network computer. Computer 100 also preferably includes agraphical user interface (GUI) that may be implemented by means ofsystems software residing in computer readable media in operation withincomputer 100.

With reference now to FIG. 2, a block diagram of a data processingsystem is shown in which the present invention may be implemented. Dataprocessing system 200 is an example of a computer, such as computer 100in FIG. 1, in which code or instructions implementing the processes ofthe present invention may be located. Data processing system 200 employsa peripheral component interconnect (PCI) local bus architecture.Although the depicted example employs a PCI bus, other bus architecturessuch as Accelerated Graphics Port (AGP) and Industry StandardArchitecture (ISA) may be used. Processor 202 and main memory 204 areconnected to PCI local bus 206 through PCI bridge 208. PCI bridge 208also may include an integrated memory controller and cache memory forprocessor 202. Additional connections to PCI local bus 206 may be madethrough direct component interconnection or through add-in boards. Inthe depicted example, local area network (LAN) adapter 210, smallcomputer system interface SCSI host bus adapter 212, and expansion businterface 214 are connected to PCI local bus 206 by direct componentconnection. In contrast, audio adapter 216, graphics adapter 218, andaudio/video adapter 219 are connected to PCI local bus 206 by add-inboards inserted into expansion slots. Expansion bus interface 214provides a connection for a keyboard and mouse adapter 220, modem 222,and additional memory 224. SCSI host bus adapter 212 provides aconnection for hard disk drive 226, tape drive 228, and CD-ROM drive230. Typical PCI local bus implementations will support three or fourPCI expansion slots or add-in connectors.

An operating system runs on processor 202 and is used to coordinate andprovide control of various components within data processing system 200in FIG. 2. The operating system may be a commercially availableoperating system such as Windows XP, which is available from MicrosoftCorporation. An interpreter, a virtual machine, or other run-timeplatform, such as a JAVA™ Virtual Machine, may run in conjunction withthe operating system and provides calls to the operating system fromprograms in the JAVA™ programming language or other applicationsexecuting on data processing system 200. Instructions for the operatingsystem, the run-time platform, and applications or programs are locatedon storage devices, such as hard disk drive 226, and may be loaded intomain memory 204 for execution by processor 202.

Those of ordinary skill in the art will appreciate that the hardware inFIG. 2 may vary depending on the implementation. Other internal hardwareor peripheral devices, such as flash read-only memory (ROM), equivalentnonvolatile memory, or optical disk drives and the like, may be used inaddition to or in place of the hardware depicted in FIG. 2. Also, theprocesses of the present invention may be applied to a multiprocessordata processing system.

For example, data processing system 200, if optionally configured as anetwork computer, may not include SCSI host bus adapter 212, hard diskdrive 226, tape drive 228, and CD-ROM 230. In that case, the computer,to be properly called a client computer, includes some type of networkcommunication interface, such as LAN adapter 210, modem 222, or thelike. As another example, data processing system 200 may be astand-alone system configured to be bootable without relying on sometype of network communication interface, whether or not data processingsystem 200 comprises some type of network communication interface. As afurther example, data processing system 200 may be a personal digitalassistant (PDA), which is configured with ROM and/or flash ROM toprovide non-volatile memory for storing operating system files and/oruser-generated data.

The depicted example in FIG. 2 and above-described examples are notmeant to imply architectural limitations. For example, data processingsystem 200 also may be a notebook computer or hand held computer inaddition to taking the form of a PDA. Data processing system 200 alsomay be a kiosk or a Web appliance.

The processes of the present invention are performed by processor 202using computer implemented instructions, which may be located in amemory such as, for example, main memory 204, memory 224, or in one ormore peripheral devices 226-230.

The present invention provides a method, computer program product, anddata processing system for modifying attributes of GUI componentswithout invasive code modification. According to a preferred embodimentof the present invention, a set of GUI component attributes are loadedfrom persistent storage in a markup language, and the set of GUIcomponent attributes are recursively applied to a set of instantiatedGUI components in a run-time environment.

These terms are defined as follows: A “set” is an aggregation of zero ormore items. A “GUI component” is a constituent element of a graphicaluser interface (GUI). An “attribute” of a GUI component is informationthat defines a property of the component; some examples of attributesinclude, but are not limited to, display attributes defining theappearance of a GUI component, behavior attributes defining the behaviorof a GUI component, and informational attributes that definemiscellaneous information to be associated with the component.“Persistent storage” is a storage system or medium for storing data inwhich the data is stored in a way that preserves the data during periodsof time in which an item of computer software that uses the data is notexecuting. A “markup language” is a human-readable language forexpressing data in which textual data is given a computer-discernablesemantics by the annotation of the textual data with computer readabletags.

To “instantiate” a GUI component means to create a representation (an“instance”) of a particular GUI component in a data processing system,usually in the memory of the data processing system. The concept ofinstantiating a component can be roughly described as “making” thecomponent. Thus, a computer program that has code that defines theoperation, behavior, and appearance of a “button” GUI component will nothave “instantiated” a “button” until a representation of a particular“button” is created. In the context of GUI components that are definedas classes (e.g., in an object-oriented programming language), thisrepresentation will generally be an object that is an instance of theclass. For the purposes of the this specification and the accompanyingclaims, however, representations of a particular GUI component in a dataprocessing system that are not objects, in the object-oriented sense,are also said to be “instantiated.”

A “run-time environment,” for the purposes of this specification and theaccompanying claims, is a process, thread, memory space, virtualmachine, data storage, or other entity in a data processing system, inwhich the process, thread, memory space, virtual machine, data storageor other entity is associated with computer software under execution. Adata processing system performs an action “recursively” when the actionis performed by a function, method, procedure, or other form of routinethat re-invokes itself in a self-referential manner (e.g., a functionthat contains a function call to itself).

Turning now to FIG. 3, a diagram of a file in eXtensible Markup Language(XML) representing a set of attributes for GUI components in accordancewith a preferred embodiment of the present invention is provided. XML isa standard for a markup language that was developed by the World WideWeb Consortium (W3C). XML is called eXtensible Markup Language, becauseit allows for the creation of user-defined tags. For example, the tagsemployed in the file depicted in FIG. 3 are defined to represent GUIcomponents and their attributes. The file depicted in FIG. 3 is, in apreferred embodiment, stored in some kind of persistent storage, such ason disk, or in a database. One of ordinary skill in the art willrecognize that any of a number of different storage formats and mediamay be employed to store GUI component attribute information inaccordance with the teachings of the present invention.

In a preferred embodiment, a set of attributes, such as are stored inthe file depicted in FIG. 3, will be loaded into the memory space of arun-time environment. Then, an attribute application routine, such asthat depicted in pseudo-code form in FIGS. 6A-6B, is executed to applythe set of attributes to instantiated GUI components in the run-timeenvironment. This allows global or at least wide-spread changes to GUIattributes to be made in a single line of code (i.e., a call to theattribute application routine), thus preventing major code revisions. Italso allows display attribute information to be decoupled from theprogram code itself (i.e., by use of a file or database, such asdepicted in FIG. 3), so that once the small amount of code needed tocall the attribute application routine is inserted in a program,attributes may be redefined without resorting to code changes at all.

Turning now to the specifics of FIG. 3, GUI component attributeinformation in this preferred format is surrounded by begin and end tags300. Begin and end tags 300 identify that the information containedwithin begin and end tags 300 refer to GUI component attributes (alsocalled properties). In many markup languages, such as the XML markuplanguage that is depicted in FIG. 3, data is arranged in a hierarchicalformat. In the XML example in FIG. 3, begin and end tags 300 represent ahighest level in the hierarchy of information provided in the filedepicted in FIG. 3. Each level in the hierarchy is represented by tagsthat surround information at lower levels in the hierarchy. For example,tags 302 and tags 318 denote two sets of information residing at thenext lowest level in the hierarchy from begin and end tags 300.

Tags 302 represents the default attributes for a “button” GUI component.At the next lowest level from tags 302 are tags 304 and tags 306. Tags304 and tags 306 denote different display modes, namely a day mode and anight mode. The run-time environment making use of the set of attributesprovided in FIG. 3 may specify that the run-time environment isoperating in a particular display mode. For example, during the day, therun-time environment may operate in a “day mode,” while the run-timeenvironment may operate in a “night mode” for easier viewing at night.Tags 304 represent that the information contained within tags 304corresponds to attributes of a button to be applied when the run-timeenvironment is operating in day mode. Likewise, tags 306 denote that theinformation contained within tags 306 corresponds to attributes to beapplied to a button GUI component when the run-time environment isoperating in night mode.

The information contained within tags 304 corresponds to the individualattribute to be applied to a button GUI component in day mode. Line 308,for example, specifies a background color for a button GUI component tobe applied in day mode. Tags 309 designate that the attribute ofbackground color is specified. Text 311, which is surrounded by tags309, is the actual specified background color. Note that text 311 is nota tag, but is merely textual data. In a markup language such as XML,tags are generally used to provide structure to the data, but the dataitself may be specified as raw text, as is the case with text 311. Line310 similarly specifies a foreground color attribute by surroundingtextual data with tags. Tags 312 are included in this example to showthat individual attributes may include their own sub hierarchy ofsub-attributes. Tags 312 denote that the information contained withintags 312 specifies the font to be applied to a button GUI component inday mode. A specific font, however, is generally specified using morethan one item of information. Line 314, which is contained within tags312, specifies a font name, while line 316 specifies a type of font,such as bold face or italics. Each of these sub-attributes is specifiedby surrounding textual data with tags that impart a meaning andstructure to the data. For example, line 314 includes tags 315 thatspecify that the information contained within tags 315 is the name offont to be used. Text 317, which is contained within tags 315, is theactual designation of a particular font name.

The information contained within tags 302, just examined, specifiesdefault attributes to be applied to button GUI components in either of aday mode and a night mode. Tags 318 also specify a set of GUI attributesto be applied to a button GUI component, but tags 318 correspond toattributes to be applied to a specifically named button GUI component. Atag attribute 320 is included within the first of tags 318 to specifythat tags 318 correspond to GUI component attributes to be applied to aspecifically named button GUI component. In the example presented inFIG. 3, tag attribute 320 is used to designate that the name of thespecific button GUI component to which the attributes contained withintags 318 correspond is “OK.” Allowing specific GUI components to benamed within the set of attributes allows exceptions to be made to thedefault GUI component attribute settings for particular components. Forexample, it may be useful to establish global or default settings forbutton GUI components or other GUI components, while at the same timespecifying that certain GUI components have different attributes, suchas in the case of an “OK” or “Accept” button, where it may be desirableto make the button more conspicuous on the user's display.

A preferred embodiment of the present invention applies a set ofattributes, such as are depicted in FIG. 3, to some or all of theinstantiated GUI components associated with a run-time environment.FIGS. 4-6B concern how a set of GUI attributes, once loaded into memory,may be applied to a set of GUI components containing all or some of theinstantiated components in a run-time environment. A preferredembodiment of the present invention accomplishes this application of GUIcomponent attributes over a set of GUI components by exploiting thecontainment relation between container components and GUI componentscontained within container components. In an object-oriented programminglanguage or other programming environments supporting object or objectmodels, the relation between GUI components and their containers iseasily expressed in terms of classes.

FIG. 4 is a class diagram depicting a relationship between GUIcomponents and containers in a preferred embodiment of the presentinvention. FIG. 4 is expressed in a notation that is based roughly onUniform Modeling Language (UML), an standard for writing softwarespecifications that is maintained by the industry organization OMG(Object Management Group). FIG. 4 assumes that GUI components areinstances of object-oriented classes. In FIG. 4, a component class 400is defined as a base class for all GUI components. As a containercomponent is a type of GUI component, a container class 402 is descendedfrom (inheritance relation 404) component class 400. Container class 402may be related to one or more instances of component class 400 viacontainment relation 406. In an actual embodiment, containment relation406 may be represented as a data structure accessible to instances ofcontainer class 402 via a member variable, such that this data structuremay contain pointers or other references to instances of component class400. A method 408 of container class 402 is defined so as to return thelist or set of instances of component class 400 that are contained by aninstance of container class 402. In the AWT API provided with the JAVA™programming language, component class 400 corresponds to the“java.awt.Component” class and container class 402 corresponds to the“java.awt.Container” class. In the java.awt.Container class, method 408is called “getComponents.”

One of ordinary skill in the art will recognize that because ofpolymorphism, an instance of container class 402 may contain anyinstance of a GUI component class that is descended from component class400. This means that an instance of container class 402 may also containanother instance of container class 402, as container class 402 isdescended from component class 400. Thus, a graphical user interfacepatterned after the object model provided in FIG. 4 will utilize GUIcomponents arranged in a hierarchical structure according to acontainment relation that relates container components to componentscontained within the container components. Such a hierarchy is depictedin FIG. 5.

FIG. 5 shows a container component 500 that contains both anothercontainer component 502 and a non-container component 504. Containercomponent 502 also contains another non-container component 506. As canbe seen from FIG. 5, this hierarchical arrangement of containers andnon-container components has a tree-like structure. Container 500 canbest be considered a “root container” because container component 500defines a hierarchically structured set of GUI components that are, atleast in a transitive sense, contained by container component 500. Apreferred embodiment of the present invention applies GUI componentattributes to each of the GUI components within the hierarchical setdefined by container component 500 by traversing the tree-like hierarchyand applying appropriate GUI attributes to each component. One ofordinary skill in the art will recognize that a tree-like hierarchy canbe traversed in a number of different ways. For example, depth-firstsearch and breadth-first search are two well-known techniques forexhaustively traversing a tree-like hierarchy. Depth-first search andbreadth-like search are described generally in Cormen, Lieserson, Rivestand Stein, Introduction to Algorithms Second Edition, MIT Press, 2001,pp. 526-560.

FIGS. 6A and 6B are diagrams of an attribute application routine (inthis case, a method) for applying attributes to GUI components in aJAVA™-like pseudo-code in accordance with a preferred embodiment of thepresent invention. FIGS. 6A and 6B are intended to be read together as asingle listing of pseudo-code, with FIG. 6B providing a continuation ofthe listing, which starts in FIG. 6A. In this discussion, it is assumedthat a set of attributes to be applied has been loaded into memory(e.g., from a file or other persistent storage such as the XML file inFIG. 3) and the GUI components to which the attributes will be appliedhave already been instantiated.

Turning now to FIG. 6A, line 602 defines a method 600 for applying GUIattributes to GUI components. Line 602 specifies that a root container,called “container” (here italicized to distinguish the identifier namefrom the generic term “container), is passed in as an argument to method600. Throughout this discussion, we will refer to the object passed intomethod 600 as “container,” since that is the name of the parameter thatrefers to that object. It should be noted, however, that, strictlyspeaking, “container” is a parameter that only refers to an actualobject and that actual object has its own object name that existed fromwhen the object was instantiated. That object name will generally bedistinct from the name “container.” In this discussion, it will bespecifically noted when container is used to refer to the parameteronly, rather than to the object referred to by the container parameter.

It should also be noted that, although it is not depicted in FIG. 6A,method 600 may be written so as to allow a “mode” parameter to be passedin to allow only those attributes pertaining to a particular displaymode, specified by the “mode” parameter, to be applied to instantiatedGUI components. Another way in which a display mode can be specified isto set a “mode” variable that can be accessed by the routines andsub-routines that will apply attributes to instantiated GUI components,such as method 600 and the method called on line 610, for example.

Execution of method 600 begins with statement 604, which specifies thatif container is a null pointer “i.e., container does not refer to anactual container”, method 600 should be exited immediately to avoidtriggering an error condition or exception.

Next, properties are set for container. “if” statement 606 sets outinstructions to be followed in the case that container refers to aJPanel. “if” statement 608 specifies that statement 610 should beexecuted if container refers to a container that is specifically namedin the set of GUI component attributes to be applied (e.g., as in FIG.3). “if” statement 608 makes use of an object called “named” todetermine whether the object name of container (i.e., the name given atthe time of instantiation to the object referred to by the parametercontainer) is among the names of specifically named GUI components fromthe set of attributes to be applied. A method called “getName” that isassociated with the class Container (as in the “java.awt.Container”class in the JAVA™ programming language) is used to retrieve container'sname. Statement 610, which is called if container refers to a containerthat is specifically named in the set of attributes to be applied (e.g.,such as the button named “OK” in FIG. 3), calls a method that takescontainer and container's object name as arguments and assignsattributes from the set of attributes to container based on thespecified attributes in the set of attributes that correspond to thecontainer's object name. In this object-oriented preferred embodiment,the actual setting of GUI component attributes is accomplished bycalling methods that belong to the objects that represent the GUIcomponents. For example, the method called in statement 610 will executemethods of container in order to set the attributes of container tovalues specified in the loaded set of attributes.

“else” statement 612 executes statement 614 to apply the defaultattributes to container in the event that container is not aspecifically named container in the set of attributes to be applied. Inlike fashion, additional “if” statements, such as “if” statement 606,maybe used to apply appropriate attributes to the container according tothe type of container (e.g., panel, window, dialog box, etc.).

Assignment statement 616 uses the “getComponents” method of container toobtain an array of components that are contained by container. “if”statement 618 then specifies that if container contains no components,method 600 should terminate immediately, as no further processing oncontainer is necessary. Otherwise, loop statement 620 sets up a loopthat iterates over the array of components contained within container. Aseries of if statements are used to determine the type of component thatis current component in the loop and whether the current component is aspecifically named component in the set of attributes, such thatspecific attributes for that component should be applied from the set ofattributes.

For example, “if” statement 622 specifies a set of instructions to beexecuted if the current component is an instance of a JButton, a JAVA™Swing GUI component. If the current GUI component is an instance of aJButton, “if” statement 624 determines whether the current component isa specifically named JButton in the set of attributes. If the currentcomponent is a specifically named JButton in the set of attributes,statement 626 provides a call to a method to apply attributes to thecurrent component that correspond to the object name of the currentcomponent. Otherwise, “else” statement 628 specifies that statement 630is to be executed to apply default JButton attributes to the currentcomponent. After either statement 626 or statement 630 is executed,“continue” statement 632 is executed to advance the loop to the nextcomponent contained by the container. “if” statement 634, whichcontinues into FIG. 3B, sets out a similar set of instructions to befollowed in the case that the current component is an instance of aJLabel component, another JAVA™ Swing GUI component. Likewise, for eachadditional non-container component type, a similar set of instructionsis provided to allow appropriate attributes to be applied with respectto the type of the current component considered in the loop and, ifapplicable, the object name of the current component. This isrepresented by comment line 646.

“if” statement 648 is the last statement to be executed at eachiteration of the loop defined by loop statement 620. “if” statement 648specifies that if the current component is an instance of the containerclass (i.e., the current component is itself a container), method 600 isto be called recursively with the current component passed as anargument to method 600. The recursive call performed as part of “if”statement 648 causes method 600 to implement a depth-first search.

It should be noted at this point that although method 600 performs adepth-first traversal recursively, method 600 need not be implemented asa recursive method. For example, method 600 could be implementediteratively, by employing an appropriate data structure, such as a stackor queue, to keep a running record of components that have beendiscovered, but have yet to be examined. One of ordinary skill in theart will recognize that, in general, a recursive method or function suchas method 600, can usually be implemented in an iterative (i.e.,non-recursive) form, as this is a general principle of computer science.

FIG. 7 is a flowchart representation of a process followed by run-timeenvironment to apply attributes to instantiated GUI components in apreferred embodiment of the present invention. The set of attributes tobe applied is loaded, preferably from persistence storage (block 700).GUI components for the run-time environment are instantiated (block702). It should be noted that blocks 700 and 702 may also be executed inthe reverse order. Properties are applied to the instantiated GUIcomponents by calling an attribute application routine with the rootcontainer of the instantiated GUI components passed to the routine of aparameter (block 704).

FIG. 8 is a flowchart representation of a process followed by anattribute application routine to apply attributes to GUI components in ahierarchical set of GUI components in accordance with the preferredembodiment of the present invention. A root container for thehierarchical set of GUI components is received, preferably as aparameter to the attribute application routine (block 800). Adetermination is then made as to whether the root container is aspecifically named component in the set of attributes to be applied(block 802). If the container is a specifically named component (block802: yes), then attributes are applied to the container based on thecontainers name (block 804). Otherwise (block 802: no), defaultattributes are applied to the container based on the containers type(block 806). If any components are contained by the container (block808: yes), execution progresses to block 812. Otherwise (block 808: no),execution of the attribute application routine terminates (block 810).It should be noted that block 808 establishes a loop that iterates overthe set of components contained within the container. Thus, theremaining blocks (blocks 812-820, even numbers) refer to a currentcomponent, meaning the component currently being considered by the loopdefined by block 808 over the set of components contained within thecontainer.

Referring now to an iteration of the loop as it begins in block 812, ifthe current component is itself a container (block 812: yes), arecursive call is made to the attribute application routine with thecurrent component being the root container (block 814). After therecursive call in block 814 is completed, the process cycles back toblock 808 to continue the loop. If the current component is not acontainer (block 812: no), execution continues to block 816.

If the current component is a specifically named component in the set ofattributes (block 816: yes), attributes are applied to the currentcomponent based on the components name (block 818). Otherwise, (block816: no), default attributes are applied to the current component basedon the components type (block 820). Following execution of either block818 or block 820, the process cycles to block 808 to continue the loop.

It is important to note that while the present invention has beendescribed in the context of a fully functioning data processing system,those of ordinary skill in the art will appreciate that the processes ofthe present invention are capable of being distributed in the form of acomputer readable medium of instructions or other functional descriptivematerial and in a variety of other forms and that the present inventionis equally applicable regardless of the particular type of signalbearing media actually used to carry out the distribution. Examples ofcomputer readable media include recordable-type media, such as a floppydisk, a hard disk drive, a RAM, CD-ROMs, DVD-ROMs, and transmission-typemedia, such as digital and analog communications links, wired orwireless communications links using transmission forms, such as, forexample, radio frequency and light wave transmissions. The computerreadable media may take the form of coded formats that are decoded foractual use in a particular data processing system. Functionaldescriptive material is information that imparts functionality to amachine. Functional descriptive material includes, but is not limitedto, computer programs, instructions, rules, facts, definitions ofcomputable functions, objects, and data structures.

The description of the present invention has been presented for purposesof illustration and description, and is not intended to be exhaustive orlimited to the invention in the form disclosed. Many modifications andvariations will be apparent to those of ordinary skill in the art. Theembodiment was chosen and described in order to best explain theprinciples of the invention, the practical application, and to enableothers of ordinary skill in the art to understand the invention forvarious embodiments with various modifications as are suited to theparticular use contemplated.

1. A computer-based method for modifying a user interface associatedwith a run-time environment, the method comprising: retrieving datadefining a set of attributes for graphical user interface componentsfrom persistent storage, wherein the set of attributes are specified ina markup language; dynamically applying the set of attributes toinstantiated graphical user interface components associated with therun-time environment so as to modify at least a subset of theinstantiated graphical user interface components, wherein a first subsetof the set of attributes are applied to the instantiated graphical userinterface based on a type of the instantiated graphical user interface,wherein a second subset of the set of attributes are further applied tothe instantiated graphical user interface based on a name of a containerthat is named in the set of attributes, wherein the first subset ofattributes and the second subset of attributes are each smaller than theset of attributes, and wherein the instantiated graphical user interfacecomponents associated with the run-time environment are objects in anobject-oriented programming language; and automatically setting avariable to indicate a current mode for the run-time environment,wherein different subsets of attributes in the set of attributescorrespond to different modes and one of the subsets of attributes isapplied to the instantiated graphical user interface componentsaccording to the current mode.
 2. The method of claim 1, wherein thepersistent storage is a file.
 3. The method of claim 1, wherein thepersistent storage is a database.
 4. The method of claim 1, furthercomprising: identifying a root container of the instantiated graphicaluser interface components associated with the software product, whereinthe root container defines a hierarchy containing the instantiatedgraphical user interface components associated with the run-timeenvironment; and traversing the hierarchy to apply the set of attributesto each graphical user interface component as each graphical userinterface component is visited.
 5. The method of claim 1, wherein thedifferent modes are display modes.
 6. The method of claim 5, wherein thecurrent mode for the run-time environment is one of the display modes,and wherein the display modes include a day mode and a night mode.
 7. Acomputer-based method for modifying a user interface presented by asoftware product, the method comprising: establishing a data structuredefining a set of attributes for graphical user interface components,wherein the set of attributes are specified in a markup language;identifying a root container of a hierarchy of graphical user interfacecomponents, wherein the hierarchy of graphical user interface componentsis defined by a containment relation, and wherein each of the graphicaluser interface components in the hierarchy are objects in anobject-oriented run-time environment; traversing the hierarchy ofgraphical user interface components so as to visit each graphical userinterface component in the hierarchy; for each visited graphical userinterface component as each visited graphical user interface componentis visited in the hierarchy, if at least one attribute that may beapplied to the visited graphical user interface component exists withinthe set of attributes, applying the at least one attribute to thevisited graphical user interface component so as to put the visitedgraphical user interface component into compliance with the set ofattributes, wherein a first subset of the set of attributes are appliedto the visited graphical user interface based on a type of theinstantiated graphical user interface, wherein a second subset of theset of attributes are further applied to the visited graphical userinterface based on a name of a container that is named in the set ofattributes, wherein the first subset of attributes and the second subsetof attributes are each smaller than the set of attributes, and whereinthe visited graphical user in interface component is an instantiatedgraphical user interface; and automatically setting a variable toindicate a current mode for the run-time environment, wherein differentsubsets of attributes in the set of attributes correspond to differentmodes and attributes from one of the subsets of attributes are appliedto the instantiated graphical user interface components according to thecurrent mode.
 8. The method of claim 7, wherein the data structure isestablished by reading data from a file.
 9. The method of claim 7,wherein the different modes are display modes.
 10. The method of claim7, wherein the objects include container objects and other componentobjects and the container objects and other component objects aredescended from a common base class.
 11. The method of claim 7, whereinthe hierarchy of graphical user interface components is traversedrecursively.
 12. The method of claim 9, wherein the current mode for therun-time environment is one of the display modes, and wherein thedisplay modes include a day mode and a night mode.
 13. A methodimplemented in a computer for modifying a user interface presented by asoftware product, the method comprising: inserting into a program codefile a call to a routine, wherein the routine traverses a hierarchy ofgraphical user interface components and applies attributes from a set ofattributes to each of the graphical user interface components for whichapplicable attributes exist in the set of attributes, wherein the set ofattributes are specified in a markup language, wherein each of thegraphical user interface components for which applicable attributesexist comprise, together, a group of instantiated graphical userinterface components, wherein a first subset of the set of attributesare applied to the group of instantiated graphical user interface basedon a type of the instantiated graphical user interface, wherein a secondsubset of the set of attributes are further applied to the group ofinstantiated graphical user interface based on a name of a containerthat is named in the set of attributes, and wherein the first subset ofattributes and the second subset of attributes are each smaller than theset of attributes.
 14. The method of claim 13, wherein the call includesa root container parameter, wherein the root container parameteridentifies a root container associated with the hierarchy of graphicaluser interface components.
 15. The method of claim 13, wherein the callincludes a mode parameter, wherein the mode parameter identifies atleast one subset of the set of attributes and the routine applies onlythe at least one subset of the set of attributes to the graphical userinterface components in the hierarchy.
 16. The method of claim 13,wherein the program code file is a source code file.
 17. The method ofclaim 13, wherein the program code file is one of an object code file, alibrary file, a bytecode file, and an executable file.
 18. Acomputer-based method for modifying a user interface associated with arun-time environment, the method comprising: retrieving data defining aset of attributes for graphical user interface components frompersistent storage, wherein the set of attributes are specified in amarkup language, and wherein the persistent storage is one of a file anda database; dynamically applying the set of attributes to instantiatedgraphical user interface components associated with the run-timeenvironment so as to modify at least a subset of the instantiatedgraphical user interface components, wherein a first subset of the setof attributes are applied to the instantiated graphical user interfacebased on a type of the instantiated graphical user interface, wherein asecond subset of the set of attributes are further applied to theinstantiated graphical user interface based on a name of a containerthat is named in the set of attributes, wherein the first subset ofattributes and the second subset of attributes are each smaller than theset of attributes, and wherein the instantiated graphical user interfacecomponents associated with the run-time environment are objects in anobject-oriented programming language; automatically setting a variableto indicate a current mode for the run-time environment, whereindifferent subsets of attributes in the set of attributes correspond todifferent modes and one of the subsets of attributes is applied to theinstantiated graphical user interface components according to thecurrent mode, wherein the different modes are display modes, wherein thecurrent mode for the run-time environment is one of the display modes,and wherein the display modes include a day mode and a night mode;identifying a root container of the instantiated graphical userinterface components associated with the software product, wherein theroot container defines a hierarchy containing the instantiated graphicaluser interface components associated with the run-time environment; andtraversing the hierarchy to apply the set of attributes to eachgraphical user interface component as each graphical user interfacecomponent is visited.